home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
olrdrs
/
soup12.zip
/
SOUP12.DOC
Wrap
Text File
|
1993-08-17
|
40KB
|
839 lines
Simple Offline USENET Packet Format (SOUP) Version 1.2
Copyright (c) 1992-1993 Rhys Weatherley
rhys@cs.uq.oz.au
Last Update: 14 August 1993
DISTRIBUTION
Permission to use, copy, and distribute this material for any purpose
and without fee is hereby granted, provided that the above copyright notice
and this permission notice appear in all copies, and that the name of Rhys
Weatherley not be used in advertising or publicity pertaining to this material
without specific, prior written permission. RHYS WEATHERLEY MAKES NO
REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY OF THIS MATERIAL FOR ANY
PURPOSE. IT IS PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
NOTE: This document is NOT in the public domain. It is copyrighted.
However, the free distribution of this document is unlimited.
If you create a product which uses this packet format, it is suggested
that you include an UNMODIFIED copy of this document to inform your users
as to the packet format. All queries about this format, or requests for
the latest version should be directed to Rhys Weatherley at the above
e-mail address.
INTRODUCTION
For many years, the FidoNet community has been using QWK and other formats to
enable users to download their mail and conferences to be read while off-line.
This not only saves phone charges and prevents tying up BBS lines for long
periods of time; it also allows a user to use much more powerful tools on
their own machine to process the downloaded "packets" than what can be made
available in an on-line environment.
To date however, very little work has been done in the USENET and dial-in Unix
community to facilitate the same user operations. Some attempts have been
made to use QWK, but due to QWK's limitations and unsuitability for the USENET
message formats, such efforts have not been very successful.
Within USENET, the tendency seems to be either "dial-in to some other machine
and put up with it", or "set up your own USENET site". The former keeps the
user at the mercy of whatever user interfaces the admin of the other machine
sees fit to install, and the latter requires far more computing knowledge than
the average computer user is expected to have. Both of these can serve to
lock out large portions of the computer-literate public from experiencing
USENET. The latter option can also give rise to security problems in the form
of forged USENET messages, which a more controlled dial-in system avoids.
The purpose of this document is to define a new packet format which is aware
of the conventions used in the USENET community, forming a middle ground
between dial-in user interfaces and full USENET connectivity. It is not
limited to downloading USENET news however. The same format could be used
to enable a Unix user to package up their Unix mailbox and download it for
later perusal. The format is extensible to other kinds of news or conference
systems, so it is feasible, although not yet defined, that QWK or FidoNet
messages could be accomodated within the same packet as USENET messages.
REVISION HISTORY
1.2 Add COMMANDS and ERRORS files. Renamed to "Simple Offline USENET
Packet Format". A few extra fields and type codes for the AREAS and
LIST files. Message area summaries.
1.1 Add description of the LIST file. Everything else is identical to 1.0.
1.0 Original version of the document.
Previously, this document was known as the "Helldiver Packet Format" (HDPF).
A variant of HDPF, called the "Simple Local News Packet format" (SLNP) was
created by Philippe Goujard (ppg@oasis.icl.co.uk). This document combines
the features of both previous formats and the name was changed to make it
less product-oriented.
TERMINOLOGY
Packet: a set of files, collected into a compressed archive.
Message packet: the primary kind of packet which contains messages for
the user to read.
Reply packet: a special kind of packet which contains replies composed by
the user, usually in response to the messages in a message packet.
Packet generator: a program which generates packets to be downloaded and
read, and which processes uploaded reply packets.
Packet reader: a program which reads packets, usually by presenting the
messages in a packet to the user, and which generates reply packets.
Packet processor: either a packet generator or a packet reader.
Generating host: the computer on which the packet generator executes.
Reading host: the computer on which the packet reader executes.
Download: the transfer of a packet from the generating host to the reading
host. This transfer may take place in any fashion, although the
most common method is through the use of a file transfer protocol
such as Zmodem or Kermit.
Upload: the transfer of a packet from the reading host to the generating host.
Packet stream: a logical link between the generating and reading hosts over
which downloads and uploads of packets take place.
Message area: a collection of messages which are related by a common topic
or purpose. Examples of message areas include USENET newsgroups,
Unix mailboxes, and FidoNet conferences.
Reply message area: a special kind of message area which contains replies
being uploaded to a generating host.
Text file: an ASCII file consisting of lines terminated by linefeed characters
(LF, 10 decimal). Some operating systems terminate lines in a text
file by CRLF pairs: such files must be converted to LF-terminated
lines for transmission in a packet.
ANATOMY OF A PACKET
A packet is a group of files, collected into a compressed archive. The
standard compression technique defined by this document is ZIP. Other
techniques such as ARJ, ZOO, ARC, LZH, etc can also be used. It is also
possible for Unix's tar.Z format to be used to transmit packets. The minimum
requirement is a method to collect a group of files into a single packet,
and a method to expand the packet back into the original files. ZIP is
specified to provide a common compression format for packet processors.
Each of the filenames in a packet should be stored in upper case on those
systems where case matters (e.g. Unix).
The following file specifications may appear in a packet:
INFO Optional textual information.
LIST List of message areas on the generating host.
AREAS Index of the message areas within the packet.
REPLIES Index of the reply message areas from the reading host.
*.MSG Text of the messages in a particular message area.
*.IDX Index information for messages in a message area.
COMMANDS Extra commands sent along with a packet.
ERRORS Errors that occurred during the execution of commands.
Other filenames may also appear in the packet, but are not defined by this
specification, so they should be avoided by generating software, and ignored
by receiving software.
The INFO file is an optional text file which may contain any kind of textual
information from the generating system. Typically this file would only be
present if there is some kind of urgent message that must be sent to the
receiving user. Use of this file to store the name of the generating host
and other such static information is possible, but discouraged to save space
and transmission time. If such information is required, then the COMMANDS
file can be used to transfer it.
The LIST file is an optional text file which contains a list of all message
areas that are available on the generating host, together with the format of
the messages. It is specified further in the section "LIST FILE".
The AREAS file is a text file which contains an index of the message areas
present within the packet, specifying the name of the message area, the
filename the messages may be found in, and the message format. This is
specified further in the next section.
The REPLIES file is a text file which contains an index of the message areas
present within the packet that contain replies from the user which should
be mailed or posted on the generating host. In most cases, a packet will
contain either an AREAS file or a REPLIES file, but both may be present.
See the section "REPLIES FILE" below for more information.
The *.MSG files contain